As of this writing, most of the practical experience with the National Transportation Communications for ITS Protocol (NTCIP) has been based on draft versions of the standard and other documents that were designed to provide a stepping stone to full NTCIP implementation. Specifically, the documents to which software has been developed include the following:
Software for the NTCIP is being developed by a number of organizations. The full NTCIP family is described by a number of documents, including the following
The remainder of this chapter provides details relating to the various software sources that are currently available in the public domain.
Central System Software Implementations
There are four basic prototype implementations of central
systemstyled software. None of these packages were designed to operate a real
system; rather, they are designed to provide tools to the industry to test
equipment submitted as being compliant to a specific protocol.
Caltrans
Caltrans has
developed a Protocol Exerciser to test device support of the AB3418 protocol.
This exerciser can be configured to act as a "central system" (i.e., it fulfills
the role as the manager of the communications channel). The software allows a
user to send down a single message at a time and will provide an analysis of the
response received from the attached device. It supports all of the AB3418
messages, and as such is designed for signal controllers.
Washington State Department of
Transportation
The Washington State Department of
Transportation (WSDOT) has also developed a central system emulator; however,
the department's software is designed to test VMS's support of the VMS E1
protocol. It is similar to the Caltrans Exerciser in that it allows users to
send messages to a sign and it provides an analysis of the received response.
FHWA
The FHWA funded the
development of the TRB demonstration system, which includes a prototype central
system that provides control of up to 10 traffic signals and four VMSs. The
traffic signals must support AB3418, and the VMSs must support VMS E1 and/or VMS
E1.2. The central system includes the background point-to-multipoint polling as
included in the Class B Profile. Finally, it also includes support of
center-to-center communications conforming to the TMC E1.2.
NTCIP Exerciser
The FHWA is
currently funding the development of the NTCIP Exerciser software. This software
package will be able to read in any properly formatted management information
base (MIB) from a floppy disk and support the exchange of fully compliant NTCIP
messages under the direction of the operator. The package will eventually
support the creation of macros to enable the user to perform a number of
operations sequentially and to record the results. Initial versions will only
support Class B communications, but future versions will support Class A as
well.
Signal Controller
There have also been
efforts in the industry to develop device simulators, which provide a sample
device for new central system software to be tested against.
Caltrans
The previously
mentioned Protocol Exerciser that Caltrans developed can also be configured to
simulate a signal controller at a specific drop address. This emulator supports
all of the messages defined in the AB3418 protocol and responds appropriately;
it also provides full error checking as required by the AB3418.
FHWA
As a part of the effort
to prepare the TRB Demonstration, the Caltrans software was modified such that
it could be configured to respond to any drop address (i.e., it can be
configured to simulate 63 controllers simultaneously). This was useful in
verifying the operations of the central system controlling multiple devices in a
fast polling cycle.
The software was also enhanced in order to support the background point-to-multipoint polling.
Variable Message Signs
Software
packages to support VMSs have also been produced by the various development
efforts.
WSDOT
In addition to the
prototype VMS control system, WSDOT developed a VMS simulator program. Their
program supports the VMS E1 protocol and provides the appropriate responses. The
software can optionally be used to control one of the physical signs used in the
TRB demonstration. This is accomplished by the software translating the messages
to the proprietary protocol defined by the VMS.
FHWA
As a part of the TRB
Demonstration, the FHWA funded the development of a DOS-based VMS controller
that supports both the VMS E1 and VMS E1.2 protocols (i.e., both Class A and
Class B). Optionally, the software can be used to control a physical VMS through
translating messages to a proprietary protocol. Two versions of this software
were developed in order to control signs from two different manufactures for the
demonstration.
Other Devices
In addition to the above
software packages, other efforts are under way to produce simulators for other
devices.
I-95 Corridor
Work is
underway to develop a HAR simulator and a VMS simulator. These will be developed
as conformance tools for the field deployments that are under way along the I-95
Corridor.
Recommended References
There is a wide
variety of publications available that relate to the NTCIP. This section lists
some of the resource materials that have been used in the development process,
as well as the location of developed materials
World Wide Web
A wide range of
documentation is available on the World Wide Web NTCIP Home Page located at:
http://www.ntcip.org/
The site currently includes such items as these:
NTCIP Joint Standards Committee
In
addition, there are articles in the December 1995, January 1996, and April 1996
issues of the ITE Journal. Future issues of the ITE Journal will
include additional NTCIP articles, as well as a bimonthly NTCIP update section,
which will provide the most recent information regarding the NTCIP development.
The NTCIP Joint Standards Committee is also attending a variety of major industry conferences and giving presentations describing various aspects of the NTCIP. Finally, the NTCIP demonstration is being given at various conferences.
Caltrans
Caltrans also has a home page
that can be reached from a link on the above referenced page. This site includes
the following:
NEMA Technical Committee
The most
recent versions of the NEMA Standards can be obtained from:
Organizations Planning Deployment of
NTCIP
In addition to the above sources of information, other
agencies are planning NTCIP deployments, and it is the hope of the Joint
Standards Committee that the various deploying agencies will work together to
share information. Here is a partial list of agencies considering the use of the
NTCIP:
Books and Other Sources
During the
development of the standards and prototypes, a number of books were consulted;
including the following:
RFC Documents
Another important
source of information is the Internet. Electronic copies of RFC documents may be
obtained using "anonymous FTP" to the host nic.ddn.mil or ds.internic.net.
Printed copies are available from
Common Development Pitfalls
During
the development of the NTCIP demonstration, a number of issues arose in trying
to get the various components to interoperate. These issues are documented here
to provide future implementers and integraters information for their design
consideration.
Protocol-Related Issues
A
number of the problems discovered during the integration work related to invalid
interpretation of the specifications, especially relating to those clauses that
reference other specifications without providing significant detail. In order to
minimize the number of these conflicts in the future, a discussion of some of
these issues is provided below.
Bit and Byte Order
Bit and
byte order in a computer are not necessarily the same as the bit and byte order
on the transmission medium. The transmission order varies in accordance with the
guidelines of international standards. Implementations should ensure that the
representation of the most and least significant bits and bytes in the computer
accurately reflect what is sent and received on the transmission medium.
Extended Addresses
There has
been some confusion about how large a high-level data link control (HDLC)
address must be supported. NTCIP devices are required to support one-and
two-byte HDLC addresses. All addresses are odd; if the first byte of an address
is even, then the address is multibyte.
Maximum Duration Between Successive
Bytes
Many existing field devices expect incoming messages to
be a series of bytes with minimal delay between the bytes. They will time out as
an end of message when a byte is not received in 15 ms for 1,200-bps
communications. This means that consecutive messages must be separated by about
30 ms at 1,200 bps. With the simultaneous use of soft carrier turnoff this gap
must be increased by the soft carrier turnoff time. At higher transmission rates
these times are proportionally reduced.
Because of the desire for full-duplex communications, Class B NTCIP devices should be designed to support much greater durations between successive bytes as suggested in the Class B Profile. In short, the only distinguishing limit of a message is the 0x7E flag.
Response Time
The public
domain code that is available was developed using DOS and Windows; in both cases
the serial port interrupt is only checked every 50 ms. Thus, these systems do
not perform quite as well as desired; however, this was not an issue for the
demonstration.
A real product should use a serial port driver to achieve the desired performance. The desired performance is system dependent and is stored in the T2 object. Typically, this value should be in the range of 20 ms. If the data link layer of the secondary (remote device) has not received a response from the upper layers just prior to the T2 timer expiring, it should send an empty frame (assuming the poll bit was set). The secondary may not respond after the T2 timer expires.
Control Byte
The NTCIP
includes support for three control byte values. A primary can transmit an
unnumbered poll (0x33), an unnumbered information command with the poll bit set
(0x13), or an unnumbered information command without the poll bit set (0x03).
The secondary always responds with unnumbered information response with the
final bit set (0x13). (Note that these values are presented according to
Internet encoding rules.)
Frame Handling
The primary
may constantly poll each device in order to determine whether it has any
information to report. If the primary station has information to transmit with
this poll (e.g., a request), it encapsulates this data in an unnumbered
information command with the poll bit set. If there is not any information to
send, it sends an "empty" frame of six bytes called an unnumbered poll frame. If
the primary station has information to send, but does not want to give the
opportunity for the receiving device to respond (e.g., a broadcast), it sends
the data in an unnumbered information frame without the poll bit set.
When a secondary station receives an unnumbered information frame with the poll bit set or an unnumbered poll, it responds with an unnumbered information frame with the final bit set. If the secondary has any data to send with this frame, it is encapsulated within the frame. If the secondary does not have any data to send, it should send an empty frame.
When a secondary station receives an information command without the poll bit set (e.g. a broadcast message), it does not respond.
It should be further noted that these rules only deal with the data link layer. For example, a central system may send a broadcast message without a poll at the data link layer, while requesting a response at the application layer. The remote device would prepare a response at the application layer that would then be stored in the device's data link layer. This response could only be sent out after the device has received a frame with the poll bit set.
For example, if dynamic object 1 had been defined to be the time object, central could send the following byte stream:
The address indicates that it is received by everyone and the control byte prevents anyone from responding on the wire; however, the STMP byte is a SET with response. Thus, all of the devices generate responses at the application layer and they are sent to the data link layer to be transmitted. Then, the data link layer waits until permission is granted for the device to speak (e.g., an unnumbered poll frame). In this way, a central system can broadcast the time and then go back and ensure that all the devices received the message.
If the secondary has a pending response waiting at the data link layer, it should send the response immediately upon receiving a frame with the poll bit set. If the incoming frame contains information, the information should be processed. This might entail producing a new response that will be sent to the data link layer, where it will reside until the next poll is received.
A device is responsible for storing one response frame at the data link layer. If a second response is generated before the first is sent, the first response should be overwritten.
CRC Algorithm
Examples of
how to code the cyclical redundancy check (CRC) algorithm can be found in the
AB3418 code and the FHWA code used the demonstration.
Invalid Frame
When a device
receives an invalid frame it should just discard the frame. Invalid frames
include those with invalid CRCs, invalid initial protocol identifiers, etc.
Devices should not provide any response to invalid frames.
STMP Message Type Byte
To
see how the STMP Message Type Byte is coded and used, see NEMA Standards
Publication TS 3.2, National Transportation Communications for ITS Protocol,
Simple Transportation Management Framework, page 5-1.
Length Values for Variable Message
Fields
The exact meaning of this field (i.e., which bytes are
included in the count) has led to some confusion. The count value does not
include the count byte in the count (i.e., the count starts the byte after the
count byte).
Carriers
It is very
important that secondary stations on multidrop lines turn off their modem
carriers when not sending data. After responding to a poll, the carrier must be
removed from the line so that other stations may respond.
Systems Integration
In addition to those issues raised about the interpretation of the specifications, there were also issues over how systems should be designed and what should be required in procurement specifications to achieve the goal of systems interoperability. This section provides some guidance on how to approach these issues.
Number of Devices on a
Channel
The maximum number of reliable field devices on a
single modem channel is limited by the input impedance of the transmission
output circuit in the field device modems. Each of these outputs is a load on
the field device transmission line. A practical upper limit is somewhere around
15 field devices for the current technology 202 modems. Advanced 202 modems can
be used that will isolate the individual transmission circuits unless the modem
is actively transmitting. In a system with only four to seven field devices per
channel this consideration can be neglected.
MIB Issues
All NTCIP
procurements should specify that the manufacturers/developers must provide the
devices' MIB module(s) to the purchasing agency, with rights to distribute to
their agents (e.g., those persons acting on behalf of the agency). The MIBs
should be provided in ASCII format on the medium of the procuring agency's
choice. The MIBs should include all Simple Network Management Protocol
(SNMP)/Simple Transportation Management Protocol (STMP) objects that the
device(s) support.
NTCIP Byte Stream Examples
One of the
challenges of the NTCIP is to be flexible enough to not only lend itself to
other, yet undefined, application requirements of ITS, but also to meet the
demands on the communication requirements of the existing traffic control
devices. One such demand is the fact that many existing traffic control systems
have very limited bandwidth. To resolve this problem, the architects of the
NTCIPhave developed and standardized NEMA TS 3.2 - Simple Transportation
Management Framework (STMF) and NEMA TS 3.3 Class B Profile. These documents
provide a very efficient standardized methodology by which to exchange data.
Unfortunately, there is a potential with any new standard that different people may interpret the standard differently. This section is aimed at providing one interpretation of how to use these specifications in order to exchange data. The section does not form a specification in any sense, but can be used as a guide to determine where there may be inconsistencies in interpretations of the specification documents and may increase the potential of having consistent interpretations throughout the transportation community. If differences are discovered through this process, they should be raised with the NTCIP Joint Standards Committee. Over time, this section will be updated to reflect the resolution of any such differences and thus can become an even more definitive example.
Agencies implementing equipment claiming to be NTCIP compliant are encouraged to interact with agencies and individuals involved in the NTCIP development to maximize the benefits gained through sample field deployments.
Introduction
STMF specifies
multiple formats that may be used in exchanging NTCIP data, including these:
Books describing SNMP are readily available from technical bookstores; therefore, this section is limited to describing the various STMP encodings. The approach taken to demonstrate the various encodings is to present a sample process to configure the dynamic object definition table (which can not be done using dynamic objects) and then retrieving and setting the values referenced by the dynamic objects.
The examples used in this section are based on object definitions as defined in NEMA TS 3.4 - Global Object Definitions and the dynamic object definition table objects as defined in the STMF.
Definition of a Dynamic
Object
Before presenting the example, it is useful to provide
a background on what dynamic objects are. A dynamic object is conceptualized as
an aggregate of related managed objects that can be operated on as a group. The
goal is to minimize the bandwidth requirements when communicating frequently
requested sets of objects between a management station and remote devices.
Dynamic objects are designed to be defined at run time to provide the management
station with flexibility in how it communicates with an agent.
For this purpose a node has been assigned under the protocols node called the dynamic object management (dynObjMgmt) with OBJECT IDENTIFIER ::= {protocols 3}. The dynObjMgmt subtree contains two nodes, dynObjDef and dynObjData.. Details of the node assignments from the transportation node can be found in Section 4.2 of the STMF.
Formal Specification for Dynamic
Objects
Dynamic objects are formally specified in Sections 4
and 5 of the STMF. Section 4.2 identifies the position of dynamic objects in the
International Organization for Standardization tree.
Section 4.2 defines the rules for the creation and management of dynamic objects. These rules will be applied in the subsequent sections of this section.
Configuration of Dynamic
Objects
We will briefly examine the configuration of dynamic
objects as specified in section 4.2 of the standard.
Dynamic Object Definition
(dynObjDef)
The standard defines a table under the dynObjDef
node, which is used to describe which objects are contained within each dynamic
object and in which order the individual object appear within each dynamic
object.
Each row (entry) in the table identifies a specific object, in which dynamic
object it resides, and its position (order) within the dynamic object. The
dynamic object definition table with sample data is shown below:
|
|
|
|
|
|
|
|
|
4.2.6.3.4.3
|
|
|
The dynObjNumber identifies with which of the 13 dynamic objects this row of the table is associated.
The dynObjIndex identifies the order in which the associated variable will be located in the specified dynamic object.
The dynObjVariable is the object identifier and instance information of the subject data.
The dynObjOwner is used to indicate the owner of this dynamic object. The management station may optionally set the dynObjOwner to any value it desires.
The dynObjStatus indicates whether the row is valid, invalid, or under creation ; the values are explained in detail in section 4.1.4 of the standard.
Examples
The following
clauses provide sample encodings of the various message types that may be sent
according to the STMP.
Configuring a Dynamic Object
As an example, we
will define dynamic object 1 as consisting of three objects defined in NEMA TS
3.4 - Global Object Definitions. These objects were taken from one of the three
virtual tables needed to define the event log mechanism. These objects are
described in detail below after presenting the location of these objects under
the global tree:
eventLogTable ::= 1.3.6.1.4.1.1206.4.2.6.3.4
Three of the objects under the iso (1) org (3) dod (6) internet (1)
private (4) enterprises (1) nema (1206) transportation (4) devices (2) global
(6) globalReport (3) eventLogTable (4) eventLogEntry(1) node are defined as
follows:
eventLogClass OBJECT-TYPE
SYNTAX
INTEGER (0..65535)
ACCESS read-write
STATUS mandatory
DESCRIPTION
"This
object contains the event configuration ID (from the eventLogConfig Table) that
caused this table entry. It indicates the row in the eventLogConfig table
responsible for this event entry. If this object is set to zero (0) then the
associated row (in the eventLog Table) is cleared and the following rows shall
be renumbered to maintain a sequential eventNumber sequence."
::=
{eventLogEntry
3}
eventLogTime OBJECT-TYPE
SYNTAX
INTEGER (0..4228250625)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The
time that the event occurred in seconds since the epoch of 00:00:00 (midnight)
January 1, 1970 per the device's globalTime object. If the device does not have
valid date and time information, then this shall be the time in seconds since
the device is powered up."
::= {eventLogEntry 4}
eventLogValue OBJECT-TYPE
SYNTAX OPAQUE
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The
value of this object is dt to the value pointed to bt the eventConfigConpareOID
of the associated eventLogID whn the event was logged. Its length is variable."
::= {eventLogEntry 5}
Thus the OID for the three objects are:
Assuming that we are working with an STMP-compliant device that supports these three objects, we can aggregate the three objects into a dynamic object following the procedure outlined in STMF.
The virtual representation of the dynObjDef object table that is about to be
created is shown below:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
For the purposes of this example we will set the value of the dynObjOwner
to NTCIP Guide Example for each row.
The setup of the dynamic object table involves a row by row configuration of the table.
This is achieved by sending set request command(s) to the agent,
appropriately setting the values in the table. During the process of setting
these values, the dynObjStatus entry for each row is set to the value
"createRequest (2)".
According to Section 5.2.1.4 of the Standard, the Information Field shall contain the VarBindList. This is defined as
The concept of VarBindList is further explained below.
A variable represents an instance of a managed object. A variable binding, or
VarBind, refers to the pairing of the name of the variable (including the
instance, or index, of the variable) and its value. A list of, called a SEQUENCE
OF, such VarBinds or pairs is defined as a VarBindList. This concept is
reflected in the following encoding which represents the initial set up of a
dynamic object table.
The byte stream has been modified according to the rules in 5.1.2 of the Standard. Rule (d) states that the OBJECT IDENTIFIER fields shall be interpreted as in 5.1.1.3. This means that if the Object ID Field of the PDU Header Field is 0 (nema node), then the stream is modified and encoded as indicated below. If the object ID Field of the PDU Header Field was 14 (0xE) then the objects would have to be specified from the ISO node (the struck-out bytes would be added, and the length values would be adjusted accordingly).
90 STMP SET REQUEST from NEMA 30 81 D2 Sequence (0x30) with length defined in 1 byte (0x81) and the length value is 210 bytes (0xD2) 30 14 Sequence of 20 bytes (0x14) (name-value pair) 06 08 OID of length = 8 bytes (0x08) follow 04 01 03 01 01 03 OID of dynObjVariable (1.3.6.1.4.1.1206.4.1.3.1.1.3) from the nema node 01 01 Index (dynObjNumber, dynObjIndex) 06 08 OID of length = 8 bytes (0x08) follow 04 02 06 03 04 03 OID of eventLogID (1.3.6.1.4.1.1206 4.2.6.3.4.3) from the NEMA node 03 01 index for eventLogClass=3 and eventLogNumber=1 30 1F Sequence of 31 bytes (0x1F) (name-value pair) 06 08 OID of length = 8 bytes (0x08) 04 01 03 01 01 04 OID of dynObjOwner (1.3.6.1.4.1.1206.4.1.3.1.1.4) 01 01 from nema node and index 04 13 The value which is an Octet string of 19 bytes follow 4E 54 43 49 50 20 47 75 69 64 65 20 45 78 Value of dynObjOwner = NTCIP Guide Example 61 6D 70 6C 65 30 0D Sequence of 13 bytes (0x0D) (name-value pair) 06 08 OID of length = 8 bytes (0x08) follow 04 01 03 01 01 05 OID of dynObjStatus (1.3.6.1.4.1.1206.4.1.3.1.1.5) 01 01 and index 02 01 02 Value of dynObjStatus (Integer= 02, Length =1, Value =2 [Create Request]) 30 14 Sequence of 20 bytes (0x14) (name-value pair) 06 08 OID of length = 8 bytes (0x08) follow 04 01 03 01 01 03 01 02 OID of dynObjVariable from NEMA and index 06 08 OID of length = 6 bytes follow 04 02 06 03.04.04 03 01 OID of eventLogTime from NEMA and index 30 1F Sequence of 31 bytes (0x1F) (name-value pair) 06 08 OID of length = 6 bytes (0x06) follow 04 01 03 01 01 04 01 02 OID of dynObjOwner from NEMA and index 04 13 The value which is an Octet string of 19 bytes follow 4E 54 43 49 50 20 47 75 69 64 65 20 45 78 Value of dynObjOwner = NTCIP Guide Example 61 6D 70 6C 65 30 0D Sequence of 13 bytes (0x0D) (name-value pair) 06 08 OID of length = 8 bytes (0x08) follow 04 01 03 01 01 05 01 02 OID of dynObjStatus from NEMA and index 02 01 02 Value of dynObjStatus (Integer= 02, Length =1, Value =2 [Create Request]) 30 12 Sequence of 18 bytes (0x12) (name-value pair) 06 06 OID of length = 8 bytes (0x08) follow 04 01 03 01 01 03 01 03 OID of dynObjVariable from nema and index 06 06 OID of length = 8 bytes follow 04 02 06 03 04 05 03 01 OID of eventLogValue from NEMA and index 30 1F Sequence of 31 bytes (0x1F) (name-value pair) 06 08 OID of length = 8 bytes (0x08) follow 04 01 03 01 01 04 01 03 OID of dynObjOwner from nema and index 04 13 The value which is an Octet string of 19 bytes follow 4E 54 43 49 50 20 47 75 69 64 65 20 45 78 Value of dynObjOwner = NTCIP Guide Example 61 6D 70 6C 65 30 0D Sequence of 13 bytes (0x0D) (name-value pair) 06 08 OID of length = 8 bytes (0x08) follow 04 01 03 01 01 05 01 03 OID of dynObjStatus from nema and index 02 01 02 Value of dynObjStatus (Integer= 02, Length =1, Value =2 [Create Request])
The complete Class B Profile encoding of this message is as shown below
(encoded as an unnumbered information frame with the poll bit set):
7E YY 13 C1 90 30 81 D2 30 14 06 08 04 01 03 01 01 03 01 01 06 08 04 02 06 03 04 03 03 01 30 1F 06 08 04 01 03 01 01 04 01 01 04 13 4E 54 43 49 50 20 47 75 69 64 65 20 45 78 61 6D 70 6C 65 30 0D 06 08 04 01 03 01 01 05 01 01 02 01 02 30 14 06 08 04 01 03 01 01 03 01 02 06 08 04 02 06 03 04 04 03 01 30 1F 06 08 04 01 03 01 01 04 01 02 04 13 4E 54 43 49 50 20 47 75 69 64 65 20 45 78 61 6D 70 6C 65 30 0D 06 08 04 01 03 01 01 05 01 02 02 01 02 30 14 06 08 04 01 03 01 01 03 01 03 06 08 04 02 06 03 04 05 03 01 30 1F 06 08 04 01 03 01 01 04 01 03 04 13 4E 54 43 49 50 20 47 75 69 64 65 20 45 78 61 6D 70 6C 65 30 0D 06 08 04 01 03 01 01 05 01 03 02 01 02 XX XX 7E
XX XX = CRC for stream
YY = Address to which the message is to be sent
STMP Set Response from NEMA
Assuming that the
receiving device sucessfully received the data packet, it should respond with an
STMP Set Response with encoding from the same reference node (in this example
from NEMA). The encoding will be as follows:
D0 STMP SET RESPONSE from NEMA
The complete Class B Profile encoding of the data packet is as shown
below:
7E YY 13 C1 D0 XX XX 7E
XX XX = CRC for frame
YY = device address
STMP Set Request from Root
The final step is
to activate the table as a dynamic object, and this is done by setting the
dynObjStatus for each row to valid (1). This operation could be (and
likely would be) done with encoding from the NEMA node, but this example encodes
it from the root node for explanatory purposes. The encoding will then be as
follows:
9E STMP SET Request from Root 30 42 Sequence of 66 bytes (0x42) bytes 30 14 Sequence of 20 bytes (0x14) (Pair: OID and its value follow 06 0F OID of length = 15 bytes (0x0F) follow 2B 06 01 04 01 89 36 04 01 03 01 01 05 OID of dynObjStatus from root node 01 01 Index 02 01 01 Value of dynObjStatus (Integer= 02, Length=1, Value = 1 [Valid]) 30 14 Sequence of 20 bytes 06 0F OID of length = 15 bytes follow 2B 06 01 04 01 89 36 04 01 03 01 01 05 OID of dynObjStatus from root 01 02 Index 02 01 01 Value of dynObjStatus 30 14 Sequence of 20 bytes 06 0F OID of length = 15 bytes 2B 06 01 04 01 89 36 04 01 03 01 01 05 OID of dynObjStatus from root node 01 03 Index 02 01 01 Value of dynObjStatus
STMP Set Response from Root
Again, the
receiving device would indicate that it sucessfully received the data
packet.
The encoding will be as follows:
DE STMP SET RESPONSE from Root
Once the dynamic object table structure is created with the above sequence of operations, the management station can efficiently GET and SET the values referenced by the associated dynamic object whenever the need arises.
STMP Dynamic Object Get Request
A GET request
for the data referenced by the dynamic object can be performed in just 1 byte of
application layer encoding as follows:
|
|
|
|
The resulting Class B Profile byte stream (including header and footer
information) will look as follows:
7E YY 13 C1 81 XX XX 7E
Explanation of the Event Log
In the example
detailed above, dynamic object 1 consists of data from the event log table.
Thus, in order to understand what will be returned from a get request for this
dynamic object, one must first understand the event log.
The contents of the event log are defined in the event log configuration
table as depicted below. The user configures this table to define which events
should be logged in the event log table.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Each defined event has a unique ID to distinguish the event. Whenever this event occurs, it is recorded in the event log table under the class identified in the configuration table. Events are defined based on certain conditions becoming true. The mode variable identifies the type of event (e.g., on-change, when equal to, exceeds, etc) and the compare values indicate the values to use in the comparison defined in the mode (e.g., when exceeds compare value). The compare OID field references the variable to use in the comparison (e.g., when temperature exceeds compare value). The Log OID references the variable that should be logged when the event becomes true (e.g., when temperature exceeds compare value log the status of the fans). Finally, the configuration action variable identifies whether this event should be logged or whether it is disabled (other options may be added in the future, such as returning a trap when the condition occurs).
For the purpose of this example, it is assumed that there is a entry in the event configuration table as follows:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The phaseStatusGroupGreens (from TS 3.5) object indicates which of the phases are currently active within a particular phase group. The first phase group (identified by the ".1" index extension) indicates the status of the first eight phases. Thus, whenever the green status of any of the first eight phases change, the new value of the phaseStatusGroupGreen.1 object is recorded in the Class 3 section of the log. The log entry is denoted as event ID 17. Note that for the on-change mode, the values of compare value and compare value2 are irrelevant.
The amount of space allocated to the Class 3 events is determined by the event class table. Assuming that this number is non-zero, the object referenced in our dynamic object (i.e., Class 3 Number 1) is valid.
The event log table is defined as follows with a sample entry:
|
|
|
|
|
|
|
|
|
|
|
|
The class indicates the class of the event as identified in the event configuration table. The number indicates which entry in the table (within a given Class). The ID identifies the event ID as specified in the event configuration table. The time is a time stamp of when the event occured, in this case at midnight, the morning of June 1, 1996. The value records the value of the object referenced by the associated log OID field in the event configuration table, in this case it records the value of phaseGroupGreenStatus.1 as of midnight on June 1, 1996. The value 34 represents phases 2 and 6 as being green.
With this background of the event log, and the above assumptions regarding the "current" values, we can now present the response to the above get request.
|
|
|
|
STMP Dynamic Object Set Request-No
Reply The remote device would process such a request if possible, but would not
respond (at the application layer) under any condition. This operation may be
desired if the management station is concerned about overwriting traps or other
pending responses.
STMP Dynamic Object Error Response Note: According to subsection 5.2.1.5 (Error responses) the agent will
return an error status and index number only. There is no need for the agent to
return the information contained in the set request since the manager retains
the last request transmitted to an agent in order to determine what part of the
request caused the error. Because this error response provides valuable information, the use of set
request-no reply should be used with great caution.
Other Nondynamic Examples Notice the difference in overhead between the get request for a dynamic
object and the same request for the objects treated as nondynamic objects. In
this example, the complete Class B frame for the dynamic object would be 8 bytes
and the frame for non-dynamic objects would be 45 bytes (a savings of over 82
percent!). This differential would be even greater for more complex dynamic
objects. For a process that is frequently repeated, the dynamic object option
provides a significant advantage in reducing bandwidth requirements.
STMP Get Response from NEMA In this case, the Class B frame response using nondynamic objects would be 58
bytes long versus 15 bytes for the dynamic object (a savings of almost 75
percent!) Once again, this savings becomes even more pronounced for more complex
dynamic objects.
STMP Get-Next Request from NEMA Assuming that there was a second entry of the same ID recorded at 00:00:20 on
June 1, 1996, and that the recorded green phases were four and eight, the
response would be The Get-Next Request can also be used to get a sequence of items as
follows: And the response would be: Conclusion Dynamic object implementation will be most useful for retrieving objects that
need frequent polling (e.g., traffic data in signal controllers). This means
that once the dynamic object table has been created, the dynamic values of the
objects can be frequently polled with minimal overhead
If the user wanted to send a message to set the objects
referenced by dynamic object 1, but did not want to receive a confirmation of
the response, it would send the following byte stream (using the same values as
before).
A1 Set Request-No Reply for dynamic object Number 1
11 Event Configuration ID number 17 (= 0x11 hex)
31 AF 88 00 833587200 seconds
01 A one byte value follows
22 Phases 2 and 6 are green
You may
have noticed that the above example contained an error. Both the event log time
and event log value parameters are "read only" and thus may not be set. In the
above example, this error would not be reported because the request indicated no
reply. However, if the message had been a set request instead of a set
request-no reply (e.g., a PDU Header field of 0x91 instead of 0xA1), the
following error would be returned:
E1 Error Response for Dynamic Object 1
04 the first error encountered was a read OnlyError
02 this error was encountered on the second item in the packet
The
following examples provide a contrast between the bandwidth consumption of the
dynamic objects given above and non-dynamic objects as shown below.
a get request
for the objects defined in the above dynamic object 1 would be represented as
follows:
80 GET REQUEST from the NEMA node
30 24 Sequence of 36 bytes (VarBindList) follows
30 0A Sequence of 10 bytes follows
06 08 OID of length = 8 bytes follows
04 02 06 03 04 03 OID of eventLogID from NEMA node
03 01 Index
Note: No value according to rule 5.1.2 (a)
30 0A Sequence of 10 bytes follows
06 08 OID of length = 8 bytes follows
04 02 06 03 04 04 03 01 OID & index of eventLogTime from NEMA node
30 0A Sequence of 10 bytes follows
06 08 OID of length = 8 bytes follows
04 02 06 03 04 05 03 01 OID of eventLogValue from NEMA node
The
corresponding get response would be encoded as follows:
C0 GET RESPONSE from NEMA node used as root)
30 30 Sequence of 48 bytes (VarBindList) follows
30 0D Sequence of 13 bytes follows
06 08 OID of length = 8 bytes follows
04 02 06 03 04 03 03 01 OID and Index of eventLogID from NEMA node
02 01 11 Value return (INTEGER=2, length=1, value=17)
30 10 Sequence of 16 bytes follows
06 08 OID of length = 8 bytes follows
04 02 06 03 04 04 03 01 OID and Index of eventLogTime from NEMA node
02 04 31 AF 88 00 Value return (INTEGER=2, length=4, value= 833587200 seconds)
30 0D Sequence of 13 bytes follows
06 08 OID of length = 8 bytes follows
04 02 06 03 04 05 03 01 OID of eventLogValue from NEMA node
44 01 22 Value return (OPAQUE=0x44, length=1, value=0x22)
A get-next
request can be used to retrieve instances of sequential nondynamic objects. The
object retrieved is the next object in lexicographic order. For tabular objects,
this would be the next sequential entry of the same parameter. Examples of this
are provided below.
B0 GET Next Request from NEMA
30 0A Sequence of 10 bytes
06 08 Object Identifier of 8 bytes
04 02 06 03 04 05 03 01 OID and index of eventLogValue.3.1
C0 GET Response from NEMA
30 0D Sequence of 13 Bytes
06 08 OID of 8 bytes
04 02 06 03 04 05 03 02 eventLogValue for Class 3 Number 2
02 01 88 INTEGER=2, Length=1, Value=0x88
B0 Get Next Request from NEMA
30 24 Sequence of 36 bytes
30 0A Sequence of 10 bytes
06 08 OID of 8 bytes
04 02 06 03 04 03 03 01 OID and Index of eventLogID.3.1
30 0A Sequence of 10 bytes
06 08 04 02 06 03 04 04 03 01 TLV of OID & index of eventLogTime.3.1
30 0A Sequence of 10 bytes
06 08 04 02 06 03 04 05 03 01 TLV of OID & index of eventLogValue.3.1
C0 Get Response from NEMA
30 30 Sequence of 48 bytes
30 0D Sequence of 13 bytes
06 08 OID of 8 bytes
04 02 06 03 04 03 03 02 OID & index of eventLogID.3.2
02 01 11 INTEGER of 1 byte = 17
30 10 Sequence of 16 bytes
06 08 04 02 06 03 04 04 03 02 TLV of OID & index of eventLogTime.3.2
02 04 31 AF 88 14 INTEGER of 4 bytes = 00:00:20 6/1/96
30 0D Sequence of 13 bytes
06 08 04 02 06 03 04 05 03 02 TLV of OID & index of eventLofValue.3.2
02 01 88 INTEGER of 1 byte = 0x88
There is
considerable reduction in overhead once a group of objects have been defined as
a dynamic object.